home *** CD-ROM | disk | FTP | other *** search
/ Ham Radio 2000 / Ham Radio 2000.iso / ham2000 / packet / praf205e / smack.doc < prev    next >
Text File  |  1995-04-01  |  14KB  |  309 lines
  1.  
  2. SMACK - Protocol Description
  3. ----------------------------
  4.  
  5. Version 1.0, Dated 27.02.92
  6.  
  7. by Jan Schiefer, DL5UE and Dieter Deyke, DK5SG/N0PRA
  8.  
  9.  
  10. 1. Introduction
  11.  
  12. The end of 1990 was the first time that the Stuttgart Packet-Radio-Amateurs 
  13. thought about the factual certainty of Data Security between TNC and 
  14. WAMPES(*)- Node Computer. Already with other Packet-Node Systems Data losses 
  15. had appeared, we considered which sort and in what manner a compatible  
  16. development of the KISS-Protocols with a Checksum could be considered 
  17. possible. From the Result of this consideration came the name SMACK 
  18. (Stuttgart Modified Amateur radio CRC-KISS. This Document should explain 
  19. the difference between SMACK and KISS and make possible the implementation 
  20. of other Systems. 
  21.  
  22.  
  23. 2. What is KISS?
  24.  
  25. KISS had been recommended by Phil Khan KA9Q [1]. Because his TCP/IP-Software 
  26. it needed a Protocol, that enabled a simple entry to Packet-Radio below
  27. the AX.25-Protocol level. KISS offers a layer 2a-Entry. Assignments of the 
  28. TNC are basically, only the Access Control of the Frequency (Channel-Busy-
  29. Recognition, P-Persistence-Action) and the conversion of the synchronous 
  30. HDLC-Data on the PR-Channel into the asynchronous Format of the  RS232-Port. 
  31. The KISS-Protocol regulates the demarcation of individual Packets with 
  32. Delimiters, the eventual handling n the Data Stream of the appearing 
  33. Delimiter and defines a simple Command structure for the installation of 
  34. TNC-Parameters. Also, it has met the provision, to be able to operate TNCs 
  35. with more Packet-Channels. 
  36.  
  37.  
  38. 3. Modification of the KISS-Protocol
  39.  
  40. The Host Computer communicates with KISS in the Form of Packets. The 
  41. beginning of such a Packet will be recognised through the FEND. Then 
  42. follows the so called Command Byte. It issues, whether it is handling Data- 
  43. or a Command Packet and what Command is meant. With one exception (Reset-
  44. Command = 255) all Commands employ only the lower 4 Bits of this Command 
  45. Byte. This means, that the upper 4 Bits with Multi-Channel-TNCs can issue 
  46. the Channel. So 16 Channels can be given Parameters individually. 
  47.  
  48. Because we do not know either 16- or 8-Channel-TNCs, we have used a purpose 
  49. other than originally intended, the topmost Bit of this Command Byte. If 
  50. it is set, it handles itself with the doubtful Packet as a Data Packet with 
  51. CRC (only with Data Packets are to found a Checksum calculation instead!). 
  52. With such Packets, the Checksum will be attached at the End of the Frame, 
  53. and the lower value Byte first. Both of the following illustrations show the 
  54. layout of a Data Packet once with and once without Checksum. 
  55.  
  56.  
  57. +------+------+------+------+-----+------+------+
  58. | FEND | 0x00 | DATA | DATA | ... | DATA | FEND |
  59. +------+------+------+------+-----+------+------+
  60. KISS-Frame without Checksum
  61.  
  62.  
  63. +------+------+------+------+-----+------+---------+----------+------+
  64. | FEND | 0x80 | DATA | DATA | ... | DATA | CRC LOW | CRC HIGH | FEND |
  65. +------+------+------+------+-----+------+---------+----------+------+
  66. Smack-Frame with Checksum
  67.  
  68.  
  69. It should be once again reiterated here, that only Data Packets will be 
  70. CRC-secured. With that it will be prevented, that a Command can be sent to 
  71. the TNC, when themselves Host and TNC with CRC/not CRC are in disagreement.
  72.  
  73. 4. Switching from KISS onto SMACK
  74.  
  75. A SMACK-TNC works after switching into the KISS-Modus, therefore generates 
  76. no Checksum. As soon as the first Packet is received with CRC, it switches 
  77. its Send Routines likewise to CRC. This Operation condition can be  
  78. abandoned only through a Reset. The Host behaves analogously.  If however a 
  79. KISS-TNC is connected, so CRC-Frames from the Host by reason of their 
  80. unknown Command Byte will be discarded and working continued. 
  81.  
  82. This Method has the advantage, that both KISS- as also SMACK-TNCs can be 
  83. operated alternately to a Host; without that, a reconfiguration is 
  84. necessary. That should be illustrated by a Display of both cases. 
  85.  
  86. ---------------------------------------------------------------------------
  87.  
  88. Case 1: KISS-TNC
  89.  
  90. Host                                    TNC
  91. - Sends an individual Packet with
  92.   CRC, then switches its Sender
  93.   on Normal-KISS again.
  94.                                         - Receives a frame which for
  95.                                           it is an unknown Command-
  96.                                           byte 0x80 and abandons it.
  97. - Dispatches KISS-Data without
  98.   Checksum.
  99.                                         - Dispatches KISS-Data without
  100.                                           Checksum.
  101.  
  102. ---------------------------------------------------------------------------
  103.  
  104. Fall 2: SMACK-TNC
  105.  
  106. Host                                    TNC
  107. - Sends an individual Packet with
  108.   CRC, then switches its Sender
  109.   onto Normal-KISS again.
  110.                                          - Receives a Frame with CRC-
  111.                                           Recognition, switches its 
  112.                                           Sender on CRC.
  113. - Dispatches KISS-Data without
  114.   Checksum.
  115.                                         - TNC sends the first Frame
  116.                                           with CRC.
  117. - Receives a Frame with CRC-
  118.   Recognition, switches its
  119.   Sender on CRC.
  120. - Dispatches SMACK-Data with
  121.   Checksum.
  122.                                         - Dispatches SMACK-Data with
  123.                                           Checksum.
  124.  
  125. ---------------------------------------------------------------------------
  126.  
  127. Dependent upon Send condition (CRC/not CRC) the received Frames will always 
  128. be handled as follows:
  129.  
  130.         Receiver Frame                 | Action
  131.         -------------------------------+------------------------
  132.         No CRC                         | Frame progressed further
  133.         With CRC, Correct Checksum     | Frame progressed further
  134.         With CRC, False Checksum       | Frame abandoned
  135.  
  136. This Protocol sets in advance, that a KISS-Implementation abandons its 
  137. unknown Frame. This will be promoted in the KISS-Specification [1].
  138.  
  139.  
  140. 4. CRC-Calculation and Implementation Tips
  141.  
  142. This is not the correct place, to explain the Theory of the cyclical 
  143. Redundancy-check CRC. Reference should be made to the work of Michael 
  144. Röhner, DC4OX [2]. This extract depicts only important Details for an 
  145. implementation. 
  146.  
  147. As Check Polynomial the CRC16-Polynomial will be used. This has the form
  148.  
  149.          16    15   2
  150.         X   + X  + X  + 1
  151.  
  152. The CRC-Generator will be pre-set with 0. The calculation of the CRC will be 
  153. of the CRC over all Data Bytes inclusive of the Command Byte 0x80. 
  154.  
  155. As is well known in the KISS-Protocol the demarcation of the Frame will be 
  156. performed with the FEND-Character (0xc0). In the case where this Character 
  157. occurs in the Data Stream, it will be handled otherwise. This occurrence 
  158. will be named SLIP-Encoding. 
  159.  
  160. The CRC must be calculated, before the SLIP-Encoding takes place, and will 
  161. be checked, after the SLIP-Decoding has taken place. Instead it gives more 
  162. Grounds:
  163.  
  164. - The CRC Bytes could contain FESC, TFEND, FEND etc.
  165. - The SLIP En/Decoder will be used in most Host-Implementations (e.g.
  166.   WAMPES) also dependent upon KISS, in order to make the Connection to the
  167.   Unix-Kernel as an example. Additionally, it is admitted that in this case
  168.   CRC-Checking would be desirable, but will not be understood by the other
  169.   side.
  170.  
  171. The CRCs logically belong therefore, to the KISS Layer.
  172.  
  173. Instead the Calculation is to be found as follows:
  174. - CRC-Generator pre-set with 0.
  175. - All Data Bytes one behind the other added into the Algorithm, including
  176.   both CRC-Bytes.
  177. - At the End a 0 must stand again in the CRC-Generator. If the value is not
  178.   0, so  a Transfer Error has occurred and the Frame must be discarded.
  179.  
  180. Different Algorithms for the CRC-Generator will be described in [2].
  181. Here is a simple table of a controlled Algorithm issued in the C
  182. Programming-Language, which the CRC of a Buffers (buf) calculates the
  183. Length n
  184. /*---------------------------------------------------------------------------*/
  185.  
  186. static int  calc_crc(char *buf, int n)
  187. {
  188.  
  189.   static int  crc_table[] = {
  190.     0x0000, 0xc0c1, 0xc181, 0x0140, 0xc301, 0x03c0, 0x0280, 0xc241,
  191.     0xc601, 0x06c0, 0x0780, 0xc741, 0x0500, 0xc5c1, 0xc481, 0x0440,
  192.     0xcc01, 0xcc0,  0x0d80, 0xcd41, 0x0f00, 0xcfc1, 0xce81, 0x0e40,
  193.     0x0a00, 0xcac1, 0xcb81, 0x0b40, 0xc901, 0x09c0, 0x0880, 0xc841,
  194.     0xd801, 0x18c0, 0x1980, 0xd941, 0x1b00, 0xdbc1, 0xda81, 0x1a40,
  195.     0x1e00, 0xdec1, 0xdf81, 0x1f40, 0xdd01, 0x1dc0, 0x1c80, 0xdc41,
  196.     0x1400, 0xd4c1, 0xd581, 0x1540, 0xd701, 0x17c0, 0x1680, 0xd641,
  197.     0xd201, 0x12c0, 0x1380, 0xd341, 0x1100, 0xd1c1, 0xd081, 0x1040,
  198.     0xf001, 0x30c0, 0x3180, 0xf141, 0x3300, 0xf3c1, 0xf281, 0x3240,
  199.     0x3600, 0xf6c1, 0xf781, 0x3740, 0xf501, 0x35c0, 0x3480, 0xf441,
  200.     0x3c00, 0xfcc1, 0xfd81, 0x3d40, 0xff01, 0x3fc0, 0x3e80, 0xfe41,
  201.     0xfa01, 0x3ac0, 0x3b80, 0xfb41, 0x3900, 0xf9c1, 0xf881, 0x3840,
  202.     0x2800, 0xe8c1, 0xe981, 0x2940, 0xeb01, 0x2bc0, 0x2a80, 0xea41,
  203.     0xee01, 0x2ec0, 0x2f80, 0xef41, 0x2d00, 0xedc1, 0xec81, 0x2c40,
  204.     0xe401, 0x24c0, 0x2580, 0xe541, 0x2700, 0xe7c1, 0xe681, 0x2640,
  205.     0x2200, 0xe2c1, 0xe381, 0x2340, 0xe101, 0x21c0, 0x2080, 0xe041,
  206.     0xa001, 0x60c0, 0x6180, 0xa141, 0x6300, 0xa3c1, 0xa281, 0x6240,
  207.     0x6600, 0xa6c1, 0xa781, 0x6740, 0xa501, 0x65c0, 0x6480, 0xa441,
  208.     0x6c00, 0xacc1, 0xad81, 0x6d40, 0xaf01, 0x6fc0, 0x6e80, 0xae41,
  209.     0xaa01, 0x6ac0, 0x6b80, 0xab41, 0x6900, 0xa9c1, 0xa881, 0x6840,
  210.     0x7800, 0xb8c1, 0xb981, 0x7940, 0xbb01, 0x7bc0, 0x7a80, 0xba41,
  211.     0xbe01, 0x7ec0, 0x7f80, 0xbf41, 0x7d00, 0xbdc1, 0xbc81, 0x7c40,
  212.     0xb401, 0x74c0, 0x7580, 0xb541, 0x7700, 0xb7c1, 0xb681, 0x7640,
  213.     0x7200, 0xb2c1, 0xb381, 0x7340, 0xb101, 0x71c0, 0x7080, 0xb041,
  214.     0x5000, 0x90c1, 0x9181, 0x5140, 0x9301, 0x53c0, 0x5280, 0x9241,
  215.     0x9601, 0x56c0, 0x5780, 0x9741, 0x5500, 0x95c1, 0x9481, 0x5440,
  216.     0x9c01, 0x5cc0, 0x5d80, 0x9d41, 0x5f00, 0x9fc1, 0x9e81, 0x5e40,
  217.     0x5a00, 0x9ac1, 0x9b81, 0x5b40, 0x9901, 0x59c0, 0x5880, 0x9841,
  218.     0x8801, 0x48c0, 0x4980, 0x8941, 0x4b00, 0x8bc1, 0x8a81, 0x4a40,
  219.     0x4e00, 0x8ec1, 0x8f81, 0x4f40, 0x8d01, 0x4dc0, 0x4c80, 0x8c41,
  220.     0x4400, 0x84c1, 0x8581, 0x4540, 0x8701, 0x47c0, 0x4680, 0x8641,
  221.     0x8201, 0x42c0, 0x4380, 0x8341, 0x4100, 0x81c1, 0x8081, 0x4040
  222.   };
  223.  
  224.   int  crc;
  225.  
  226.   crc = 0;
  227.   while (--n >= 0)
  228.     crc = ((crc >> 8) & 0xff) ^ crc_table[(crc ^ *buf++) & 0xff];
  229.   return crc;
  230. }
  231.  
  232. /*---------------------------------------------------------------------------*/
  233.  
  234. Saving of the Table requires 512 Bytes. If the EPROM in the TNC should 
  235. be too full for the saving of this Table, so it can be constructed as 
  236. follows for the Runtime: 
  237.  
  238. /*---------------------------------------------------------------------------*/
  239.  
  240. unsigned short Table[256];
  241. const int Rest[8] = { 0xC0C1, 0xC181, 0xC301, 0xC601, 0xCC01, 0xD801,
  242.                       0xF001, 0xA001 };
  243. main()
  244. {
  245.         int i, j;
  246.         unsigned short value;
  247.  
  248.         for (i = 0; i < 256; i++) {
  249.                 value = 0;
  250.                 for (j = 0; j < 8; j++)
  251.                         if (i & (1 << j))
  252.                                 value ^= Rest[j];
  253.                 Table[i] = value;
  254.         }
  255. }
  256.  
  257. /*---------------------------------------------------------------------------*/
  258.  
  259. If this Algorithm is to be coded in Assembler, so it requires distinctly 
  260. less space than the Saving of the Table itself.
  261. The Theory is to be found again in [2].
  262.  
  263. 5. Implementation
  264.  
  265. Previously this Protocol has been implemented in the following Systems:
  266. - WAMPES
  267. - SMACK, Version 1.3. This Software has been developed further by Jan 
  268.   Schiefer, DL5UE, from TNC2-KISS-Implementation written by K3MC. It will 
  269.   be installed especially in the TNCs of the WAMPES-NODES DB0ID (Digipeater 
  270.   Stuttgart) and DB0SAO (Mailbox Stuttgart) there it contains also, 
  271.   individual WAMPES-specific adaptations. - In the KISS of the NORD><LINK-
  272.   Firmware, from TheFirmware Version 2.4 - For the TCP/IP-Software NOS it 
  273.   gives from Thommy Osterried, DL9SAU, a 'a rundown', of the NOS developed 
  274.   from the SMACK-capabilities. 
  275.  
  276. 7. Outlook
  277.  
  278. A  desirable Implementation of this Protocol would be especially, a Packet-
  279. Driver from the 'Packet driver specification' [3]. With it would be given an 
  280. uninhibited possibility for all existing NET- and NOS-Versions without 
  281. alteration of the Source Codes. But also every other Packet-Radio-Software, 
  282. that installs the KISS-TNCs could profit from the Error Protection of the 
  283. CRC. 
  284.  
  285. This Protocol Description has a preliminary Character. The Authors 
  286. (dl5ue@db0sao, dk5sg@db0sao) are thankful for Improvement recommendations, 
  287. Advice on Error or other Comments. 
  288.  
  289.  
  290.  
  291. (*) WAMPES = Württemberg Amateurraadio Multi-Protocol-Experimental-Software. 
  292.     A software packet under UNIX, that implements multiple Protocols from  
  293.     AX.25-, TCP/IP and NET/ROM-Protocol Families and, will be installed 
  294.     mainly in the Stuttgart Area, as Net Nodes. Compare [4].
  295.  
  296.  
  297. Literature
  298.  
  299. [1] Karn, Phil, KA9Q; Proposed "Raw" TNC Functional Spec, 6.8.1986;
  300.     published in the USENET-News;
  301. [2] Röhner, Michael, DC4OX; Was ist CRC?; distributed in the Packet-Radio
  302.     Mailbox-Net, May 1988
  303. [3] FTP Software, Inc.; PC/TCP Version 1.09 Packet Driver Specification;
  304.     Wakefield, MA 1989
  305. [4] Schiefer, Jan, DL5UE; WAMPES - Weiterentwicklung; Vortrags-Skriptum
  306.     des 5. überregionalen Packet-Radio-Treffens; Frankfurt 1989;
  307.  
  308. Translation by G0KIU
  309.